Parameterized cells (pcells) have been used for more than twenty years in designing full custom chip designs. The pcells are evaluated every time the design is opened. The highly dynamic nature of pcells introduces a level of variability that the design teams may want to control.
Over the years, the use of pcells has shown three main drawbacks. The first drawback is long design opening time. Designs containing pcells are often slow to open as the code within the pcells are evaluated in order to produce the pcell design data. The second drawback is the lack of read-interoperability of the pcells. When the pcell code is written in some proprietary language such as SKILL, third party application not linking the right pcell evaluator can not evaluate the pcells, and can thus not have access to the pcell design data. The third drawback is the lack of write-interoperability of the pcells. Third party applications have difficulty correctly editing a design containing non-evaluated pcells.
Several solutions have been proposed to partially address some of these drawbacks. One solution is to translate the design into a fully evaluated, tool neutral representation, for example GDSII. The second solution is to create a complete copy of the design. Within that copy, all instances of pcell are re-mastered into instances of a regular cell, (e.g., the regular cell being a copy of the pcell instance sub-master). This process is also known as “freezing” the design. A variant of that solution replaces the sub-masters in place with a saved version of the pcell parameters, to enable later “thawing” of the design. Another solution is provided by CiraNova of Santa Clara, Calif. This solution provides a low performance cache from external observation of the behavior of the third party application in that environment. For example, in the Virtuoso environment, it replaces all SKILL pcell instances as CiraNova pcell instances. The CiraNova pcell plug-in role is to cache on disk evaluated pcell and to re-use those from disk. The evaluation is done by invoking a sub-process, e.g., a DFII subprocess, to evaluate one pcell sub-master at a time, to store it on disk as a regular master in a temporary lib/cell/view, then to copy the layout file within a cache. The re-use is done by populating the cached regular master to a temporary lib/cell/view, to open that lib/cell/view and to copy the design data from that lib/cell/view to pcell sub-master created by a system such as OpenAccess (available from www.si2.org) when evaluating a pcell with a new set of parameters.
A better solution is to allow caching of pcell sub-master contents after being evaluated within native applications. These sub-masters are persistently saved on disk in a cache. To limit the number of disk inputs and outputs (IOs), sub-masters of the same pcell are stored in the same binary file cache. When the pcell evaluator is called to generate a new pcell variant, the cache is first consulted. If the data is already available in the cache, then the sub-master is populated directly with the cached data. Otherwise, the regular sub-master evaluation process takes place, and the sub-master elements are generated to populate the variant. One approach for implementing such cached pcells is described in co-pending U.S. application Ser. No. 11/769,568, which is hereby incorporated by reference in its entirety.
When using cached pcells, it is often desirable to allow multiple users to concurrently use or have access to the cache. This is because it is possible that multiple entities (such as, for example, processes, nodes, tasks, users, and threads) and design groups would need to simultaneously access the same set of pcell data while performing design activities. However, it is quite possible that some or all of those entities and design groups are also going to be making modifications to the pcell data. As a result, significant concurrency control and consistency problems could arise if concurrent access is to be granted to multiple users. For example, consider if a first and a second user both concurrently access the same item of data from the pcell cache. If first concurrent user makes a modification to the pcell data, and the second concurrent user does not realize such a modification had occurred, then the second concurrent user could be operating upon invalid and/or inconsistent data.